AWS Glue利用時の認証とアクセス制御について(主にIAM周り)

しんや

2017.09.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Glueにアクセスするためには認証情報の設定が必要となります。これらの資格情報にはAWS GlueのテーブルやAmazon EC2インスタンスなどのAWS各種リソースにアクセスするための許可が必要となり、予めこの設定については作成・準備しておく必要があるのですが、ちょっとした手間が掛かる部分もあるため、個別に内容を細かく見て把握していきたいと思います。

AWSにおける認証についておさらい

まずは基本的なところから。AWSのリソースへは、以下の様な形で様々な方法でアクセスすることが可能となっています。

AWSアカウント rootユーザー

AWSアカウントに関連付けられたアドレスとパスワードを入力して使う事が出来るユーザー。全てのAWSリソースに対してフルアクセス可能。ちなみにAWSではセキュリティ上の観点から、このrootユーザーは直接利用せず、AWSアカウントに対してフルアクセス権限を持つIAMユーザーを作成する事だけに留めておく(IAMユーザー作成以降はそのIAMユーザーを利用する)事を推奨しています(ので従いましょう)。

IAMユーザー

特定のカスタマイズされた権限(AWS Glueのテーブル作成を行う等)を持つ、AWSアカウント内におけるID情報。IAMユーザー名とパスワードを使用してサインインします。このユーザー毎にアクセスキーを生成する事も可能。アクセスキーはSDKやAWS CLI等を利用する際の署名に用います。

AWS GlueではインバウンドAPIリクエストを認証するためのプロトコルであるSignature Version 4をサポートしています。

署名バージョン 4 署名プロセス - アマゾンウェブサービス

IAM Role

特定のアクセス許可を持つ、AWSアカウント内で利用出来る(IAMユーザーとは別種の)ID情報。IAMユーザーと似ていますが、IAM Roleは特定の人物に関連付けられているものではありません。

IAM Roleを利用する事でAWSサービス及びリソースにアクセスするために使用出来る一時的なアクセスキーを取得出来ます。以下のようなケースで活用可能です。

Federated user access(フェデレーテッドユーザアクセス)

Amazon Web Services ブログ: 【AWS発表】 AWS CloudFormationでフェデレーテッドユーザーおよび一時的なセキュリティ認証情報が利用可能に

IAMユーザーを作成する代わりにAWS Directory Service、エンタープライズユーザーディレクトリ、WebアイデンティティプロバイダのユーザーIDを使用する事が出来るもので、これらはフェデレーションユーザー(federated users)と呼ばれます。ユーザーIDを管理する「IDプロバイダー(IdP)」については以下参照。

ID プロバイダーとフェデレーション - AWS Identity and Access Management

「フェデレーション」そのものの意味としては以下のサイト辺りがイメージを掴みやすそうでしょうか。「外部認証ID連携ユーザーアクセス」的な。

フェデレーション (federation)とは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

IDプロバイダを介してアクセスが要求されると、AWSはフェデレーションユーザーにロールを割当てます。

アクセス管理の概要: アクセス許可とポリシー / フェデレーションユーザーとロール - AWS Identity and Access Management

Cross-account access(AWSアカウント間を跨いだアクセス)

AWSアカウントのIAM Roleを使用して、AWSアカウント内のリソースにアクセスする権限を別のAWSアカウントに付与する事が可能です。

AWS service access(AWSサービスアクセス)

アカウントのIAMロールを使用して、アカウントのリソースにアクセスするためのAWSサービス権限を付与できます。(例：Amazon RedshiftがAmazon S3バケットにアクセスする際に、Amazon Redshiftがバケットからクラスタにデータをロード出来るようにクラスタにRoleを割り当てる)

AWS サービスにアクセス許可を委任するロールの作成 - AWS Identity and Access Management

Amazon EC2上で稼働するアプリケーション

EC2インスタンス上で実行されているアプリケーションの一時的な認証情報を管理してAWS APIリクエストを作成出来ます。EC2インスタンス内にアクセスキーを記述・格納するよりも好ましい方法です。

EC2インスタンスにロールを割り当て、全てのアプリケーションでIAM Roleを使用可能にするには、インスタンスプロファイルを作成してインスタンスにアタッチします。インスタンスプロファイルにはRoleが含まれており、EC2インスタンスで実行されているプログラムが一時的な資格情報を取得出来るようになります。

Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス権限を付与する - AWS Identity and Access Management

IAM全般の内容については以下の再入門エントリもご参考ください。

AWS再入門 AWS IAM (Identity and Access Management) 編｜ Developers.IO

AWS Glueにおけるアクセス制御

全てのAWSリソースはAWSアカウントによって所有され、リソースを作成またはアクセスするための権限は「アクセス許可ポリシー」によって管理されます。アカウント管理者は、IAMアイデンティティ(ユーザー、グループ、ロール)にアクセス許可ポリシーを添付出来ます。また、一部サービスではアクセス許可ポリシーをリソースに関連付ける事も可能となっています。

IAMについては以下の「ベストプラクティス」についても併せて目を通しておく事をお勧めします。

IAM のベストプラクティス - AWS Identity and Access Management

AWS Glueのリソースと操作について

AWS Glueでは各種リソースに対してAPIが提供されています。現行提供されているAPIの一覧は以下の通り。充実のラインナップですね。

AWS Glue API - AWS Glue

- AWS Glue API
  - Catalog API
  - Crawlers and Classifiers API
  - ETL Scripts API
  - Jobs API
  - Common Data Types
  - Exceptions

"リソース所有権"の理解

AWSアカウントはリソースの作成者に関係無く、作成されたリソースを所有します。IAMユーザーやIAM Role等の手段を用いる場合は以下のような形で所有者とアクセス制御が構成される形となります。

AWSアカウントにおけるルートアカウント情報を使ってリソース(テーブル)を作成した場合、AWSアカウントがそのリソースの所有者となります。
AWSアカウント上で作成されたIAMユーザーに対してテーブル作成の権限を付与すると、そのIAMユーザーはテーブルを作成出来ます。この場合のテーブルリソースの所有者はAWSアカウントです。
テーブル作成権限を持つAWSアカウントでIAM Roleを作成する場合、そのIAM Roleを割り当てられたユーザーはテーブルを作成できます。この場合のテーブルリソース所有者はユーザーが所属するAWSアカウントとなります。

リソースへのアクセスの管理

「アクセス許可ポリシー」では誰が何に対してアクセス権限を持っているかを表します。

IAMアイデンティティにアタッチされたポリシーはアイデンティティベースのポリシー、すなわち「IAMポリシー」と呼ばれ、リソースに添付されたポリシーはリソースベースのポリシーと呼ばれます。AWS Glueでは前者のみをサポートしています。

IAM及びIAMポリシーについては以下ドキュメント等をご参照ください。

AWS Black Belt Online Seminar AWS Identity and Access Management (AWS IAM) from Amazon Web Services Japan

アイデンティティベースのポリシー(IAMポリシー)

IAMポリシーでは、IAMアイデンティティにポリシーを追加出来ます。主に以下のような操作です。

アカウント内のユーザーまたはグループに権限ポリシーを割り当てる：: ユーザーに対してテーブル等のAWS Glueリソースを作成する権限を与えるために、そのユーザーが属するユーザーまたはグループにアクセス許可ポリシーを付与。
ロールに対して権限ポリシーを付与(クロスアカウント権限の付与：: アイデンティティベースのアクセス許可ポリシーをIAM Roleに付与し、クロスアカウントのアクセス許可を与える。

以下はAWS Glueアクション(glue:GetTables)に対してパーミッションを付与するポリシーの例です。現在のAWSリージョン内のAWSアカウントが所有する、データベース内の全てのテーブルの名前を取得出来る...という内容になります。

Table API / GetTables Action (Python: get_tables) - AWS Glue

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetTables",
            "Effect": "Allow",
            "Action": [
                "glue:GetTables"				
            ],
            "Resource": "*"
        }
    ]
}

アイデンティティベースのポリシーをAWS Glueで利用する方法については後述します。また、ユーザーやグループ、ロール及びアクセス許可の詳細については以下ドキュメントを参考にすると良いでしょう。

ID（ユーザー、グループ、ロール） - AWS Identity and Access Management

リソースベースのポリシー

AWS Glueがサポートしているものは上述の「IAMポリシー」のみとなりますが、Amazon S3など他のサービスではリソースベースのアクセス許可ポリシーもサポートしています。Amazon S3の例で言えば「S3バケットにポリシーを割り当てて、バケットへのアクセス制御を行う」といったものが挙げられます。

ポリシー要素の指定：アクション、エフェクト、プリンシパル

AWS Glueでは各種AWS GlueリソースについてAPI操作のインタフェースを提供しており、これらAPIの操作に対して権限を付与するために「ポリシー」で指定出来る一連のアクションを定義します。

基本的なポリシーの要素は以下のものがあります。

リソース(Resource)：: Amazon Resource Name(ARN)を使い、ポリシーが適用されるリソースを識別。
アクション(Action)：: アクションキーワードを使い、許可 or 拒否するリソース操作を識別。(例:create)
エフェクト(Effect)：: ユーザーが特定のアクションを要求した際の許可 or 拒否のいずれかのエフェクトを指定。明示的にリソースへのアクセスを許可しない場合、アクセスは暗黙的に拒否されます。リソースへのアクセスを明示的に拒否する事も可能。
プリンシパル(Principal)：: IAMポリシーでは、ポリシーがアタッチされているユーザーが暗黙のプリンシパルです。「プリンシパル」については以下を参照。"「誰が」(つまり、操作する主体)の部分"という説明が分かりやすいかと思います。; IAM ポリシーエレメントのリファレンス / Principal - AWS Identity and Access Management; AWS IAMポリシーを理解する｜ Developers.IO

IAMポリシーの構文及び詳細な解説については以下のドキュメントが詳しいです。

AWS IAM ポリシーのリファレンス - AWS Identity and Access Management

ポリシーでの条件指定

アクセス許可設定を行いたい場合は「アクセスポリシー言語」を使ってポリシーを有効にする条件を指定する事が出来ます。(例：特定の日付の後にのみポリシーを適用する、等) 条件を表現する際に定義済の条件キーを使用する事も可能です。

IAM ポリシーエレメントのリファレンス / 条件(Condition) - AWS Identity and Access Management

AWS Glueにアイデンティティベースのポリシー(IAMポリシー)を活用する

AWSアカウント管理者によるIAMアイデンティティ(ユーザー、グループ、ロール)にアクセス許可ポリシーの付与、「AWS Glueリソースに対する操作」を実行する権限を付与する方法について見ていきます。

以下はAmazon DynamoDBのアクセス許可ポリシーの例です。このポリシーには、account-idで指定されたAWSアカウントが所有するオレゴン(us-west-2)リージョンの、テーブルに対する3つのDynamoDBアクション(dynamodb:DescribeTable、dynamodb:Query、dynamodb:Scan)に関するアクセス権限が付与されています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DescribeQueryScanBooksTable",
            "Effect": "Allow",
            "Action": [
                "dynamodb:DescribeTable",
                "dynamodb:Query",
                "dynamodb:Scan"
            ],
            "Resource": "arn:aws:dynamodb:us-west-2:account-id:table/Books"
        }
    ]
}

AWS Glue コンソールに必要な権限

AWS Glueコンソールで作業を行うには以下サービスからの権限が必要となります。

Amazon CloudWatch Logs権限(ログ表示)
AWS IAM権限(ロールを一覧表示して渡す)
AWS CloudFormation権限(スタック操作)
AWS EC2権限(VPC、サブネット、セキュリティグループ、インスタンス及びその他のオブジェクトを一覧表示)
Amazon S3権限(バケット・オブジェクトを一覧表示、スクリプトの取得・保存)
Amazon Redshift権限(クラスタ操作)
Amazon RDS権限(インスタンスの一覧表示)

必要最小限のアクセス権よりも厳しい制約のIAMポリシーを作成した場合、AWS Glueコンソールは機能しなくなりますので注意。後述するAWS Glueの定義済ポリシーを活用すると良いでしょう。(AWS CLIまたはAWS Glue APIの呼び出しを行う場合はこの限りではありません)

AWS Glue向けの事前定義済管理ポリシー

AWS Glueを管理・活用する際の事前定義済ポリシーとして、AWSGlueConsoleFullAccessというポリシーが定義されています。その他にも幾つかAWS Glueに関するポリシーが用意されており、ユースケースシナリオ別に活用することが出来ます。また、下記以外にも独自のIAMポリシーを作成してAWS Glueアクション及びリソースの権限を許可する事も可能です。

AWSGlueConsoleFullAccess: AWS Glueリソースへのフルアクセスを許可。ユーザーはコンソール機能をフル活用出来る。AWS Glueコンソールのユーザーに付与。
AWSGlueServiceRole: 様々なAWS Glueプロセスを実行するために必要となるリソースへのアクセスを許可。対象リソースにはAWS Glue/Amazon S3/IAM/CloudWatch Logs/Amazon EC2などがある。クローラーやジョブ、開発エンドポイントを定義する際などに付与。
AWSGlueServiceNotebookRole: ノートブックサーバの作成に必要なリソースへのアクセスを許可。対象リソースにはAWS Glue/Amazon S3/Amazon EC2などがある。開発用エンドポイントでノートブックサーバを作成する時に付与。

まとめ

という訳でAWS Glueを利用する上で必要となるIAMポリシーの詳細について見ていきました。様々なサービスを連携・活用する事で成り立っているAWS Glueなのでこの辺りの状況はちゃんと把握しておく必要があります。正確にIAMポリシーの定義・権限を把握しておく事で適切なAWS Glueの利用を心掛けていきたいものです。